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1. Status of Claims 

Claims 1, 2, 4, 11-14, 16-18, and 21-32 are pending. Claims 1, 2, 4, 11-14, 16-18, and 
21-32 stand rejected and are under appeal. Claims 3, 5-10, 15, 19, and 20 have been cancelled. 
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2. Grounds of Rejection to be Reviewed on Appeal 

Claims 1 and 16 stand rejected under 35 U.S.C. 112, first paragraph. 
Claim 32 stands rejected under 35 U.S.C. 112, first paragraph. 

Claims 1, 2, 4, 12, 14, 16, 17, and 21-31 stand rejected under 35 U.S.C. 103(a) as being 
unpatentable over U.S. Patent No. 6,986,133 to O'Brien et al. (hereinafter "O'Brien") in view of 
U.S. Patent AppUcation No. 2002/0152399 to Smith (hereinafter "Smith"). 

Claims 1 1 and 18 stand rejected under 35 U.S.C. 103(a) as being unpatentable over 
O'Brien, in view of Smith, and further in view of U.S. Patent No. 6,665,752 to Bemath (hereinafter 
"Bemath"). 

Claim 13 stands rejected under 35 U.S.C. 103(a) as being unpatentable over O'Brien, in 
view of Smith, and further in view of U.S. Patent No. 6,031,830 to Cowen (hereinafter "Cowen"). 

The preceding rejections under 35 U.S.C. §112 and 35 U.S.C. § 103(a) are presented for 
review in this Appeal. 

Regarding the grouping of the claims with respect to the rejection of Claims 1 and 16 
under 35 U.S.C. §112, first paragraph. Claims 1 and 16 stand or fall together. 

Regarding the grouping of the claims with respect to the rejection of Claim 32 under 35 
U.S.C. §112, first paragraph. Claim 32 stands or falls alone. 

Regarding the grouping of the claims with respect to the rejection of Claims 1, 2, 4, 12, 
14, 16, 17, and 21-31 under 35 U.S.C. §103(a). Claims 2, 4, 12, 14, and 21-25 stand or fall with 
Claim 1, and Claims 17 and 26-31 stand or fall with Claim 16. 

Regarding the grouping of the claims with respect to the rejection of Claims 11 and 18 
under 35 U.S.C. § 103(a), Claims 11 and 18 stand or fall together. 
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Regarding the grouping of the claims with respect to the rejection of Claim 13 under 35 
U.S.C. §103(a), Claim 13 stand or falls alone. 
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3. Argument 
A. Introduction 

In general, the present invention is directed to an application level gateway and firewall rule 
set download validation (Applicant's Specification, Title). As disclosed in the AppUcant's 
specification at page 1, lines 15-0: 

Field upgradeable products are becoming more prevalent in the broadband 
market today. Devices, such as cable modems and other bi-directional 
communication devices, may have application level gateways (ALGs) and/or 
firewall rule sets downloaded remotely to them while in a customer's home or 
office. Downloading files containing such ALGs and/or firewall rule sets places 
the device at higher risk for downloading improper file versions, corrupted files, 
non-authorized files, files that are too large, incompatibility with the device's 
hardware and/or software, among others. 

Downloading an incompatible or corrupted ALG file to a cable modem 
may cause the cable modem to hang up or crash. Once a cable modem hangs up 
or crashes, the cable modem becomes inoperable and, typically, requires a service 
call, illustratively from a multiple systems operator (MSO) service representative 
or the like, to repair the cable modem. 

Therefore, there is a need to validate proper application level gateway files 
or firewall rule set files being downloaded to a bi-directional communication 
device such as a cable modem. 

The claims of the pending invention include novel features not shown in the cited 
references and that have already been pointed out to the Examiner. These features provide 
advantages over the prior art and dispense with prior art problems such as those described above 



7 



CUSTOMER NO.: 24498 
Serial No.: 10/520,854 



PATENT 
PU020335 



with reference to the Applicant's specification. 

It is respectfully asserted that independent Claims 1 and 16 £ire each patentably distinct 
and non-obvious over the cited references in their own right. For exEimple, the below-identified 
limitations of independent Claims 1 and 16 are not shown in any of the cited references, either 
taken singly or in any combination. Moreover, these Claims are distinct from each other in that 
they are directed to different implementations and/or include different limitations. For example, 
while Claim 1 is directed to a method, Claim 16 is directed to an apparatus. Moreover, each of 
these claims includes different limitations with respect to each other. Accordingly, each of 
independent Claims 1 and 16 represent separate features/implementations of the invention that 
are separately novel and non-obvious with respect to the prior art and to the other claims. As 
such, independent Claims 1 and 16 are separately patentable and are each presented for review in 
this appeal. Moreover, dependent Claims 24, 30, and 32 are further argued separately. 

B. Whether Claims 1 and 16 Satisfy 35 U.S.C. §112, First Paragraph 

As set forth in MPEP 2163.02: 

The courts have described the essential question to be addressed in a 
description requirement issue in a variety of ways. An objective standard for 
determining compliance with the written description requirement is, "does the 
description clearly allow persons of ordinary skill in the art to recognize that he or 
she invented what is claimed." In re Gosteli, 872 F.2d 1008, 1012, 10 USPQ2d 
1614, 1618 (Fed. Cir. 1989). Under Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 
1563-64, 19 USPQ2d 1111, 1117 (Fed. Cii". 1991), to satisfy the written 
description requirement, an applicant must convey with reasonable clarity to those 
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skilled in the art that, as of the filing date sought, he or she was in possession of 
the invention, and that the invention, in that context, is whatever is now claimed. 
The test for sufficiency of support in a parent application is whether the disclosure 
of the application relied upon "reasonably conveys to the artiszin that the inventor 
had possession at that time of the later claimed subject matter." Ralston Purina 
Co. V. Far-Mar-Co., Inc., Ill F.2d 1570, 1575, 227 USPQ 177, 179 (Fed. Cir. 
1985) (quoting In re Kaslow, 101 F.2d 1366, 1375, 217 USPQ 1089, 1096 (Fed. 
Cir. 1983)). 

The Examiner rejected Claims 1 and 16 as failing to comply with the written description 
requirement. The Examiner contends that "[t]he specification does not contain subject matter 
describing the limitation of 'comparing ... a particular one compatibility parameter of said ALG 
file with both a compatibility feature of said bi-directional communication device and a non- 
signature, non-code-error checking feature expected in received and authentic ALG files'. 

Hereinafter, it will be shown that Claims 1 and 16 do, in fact, comply with the written 
description requirement and, hence, satisfy 35 U.S.C. 112, first paragraph. 

Bl. Claims 1 and 16 

Per the limitations of Claims 1 and 16, the same particular one compatibility parameter is 
compared to both a compatibility feature of said bi-directional communications device and a non- 
signature, non-code-error checking feature expected in received and authentic ALG files by said bi- 
directional communications device. 

Initially, prior to reproducing the arguments submitted in the Appeal Brief, the Applicants 
will address the Examiner's comments in the Examiner's Answer . 



9 



CUSTOMER NO.: 24498 
Serial No.: 10/520,854 



PATENT 
PU020335 



First, the Examiner is mischaracterizing the Applicants' argument when stating the 
following on page 10 of the Examiner's Answer: 

The Appellant cites a portion of the specification which states that the "ALG 
header size field 216 AND ALG body size field 224 in the header 210 of the 

received ALG file 200 ai'e checked" (emphasis added by Applicants). The 
Appellant then asserts that this passage "clearly discloses the separate use of either 
header size of body size, as well as the joint use of both, in respective compmsons" 
[See Appeal Brief Pgs 15-16]. 

That is, the Applicants did NOT simply base the preceding last sentence on solely the 
sentence before it. Rather, the entire first part of that argument in the Appeal Brief has been failed 
to be addressed or acknowledged by the Examiner, namely how both header size and body size are 
SEPARATELY DESCRIBED in other places in the specification (e.g., namely previously cited 
page 10, hnes 23-38, page 11, lines 4-5, and page 11, lines 13-14). For example, as noted in the 
first part of that argument, there is a space between the file header size and the file body size when 
each are respectively described in the specification, and other parameters are listed/described in that 
space. The separate description of the same, coupled with additional teachings that some 
(Apphcants' specification, p. 10, Unes 15-19) or aU (Applicants' specification, p. 10, lines 27-28) of 
the hsted parameters may be used, clearly discloses the use of one or both of the file header size and 
the file body size. 

Moreover, given the teachings of the present principles provided in the instant application , 
one of ordinary skill in this and related arts, when contemplating the same, would realize that any 
one of the file body size and the file header size can be used by itself as a quick check of whether 
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the overall ALG file size exceeds the memory capacity since if any one of the file header size or the 
file body size is greater than the memory capacity then clearly both will exceed that same memory 
capacity. Hence, the treating of the file header size and the file body size as separate parameters in 
the cited portions of the disclosure (e.g., AppUcants' specification, p. 10, Unes 23-28, p. 11, lines 4- 
5, and p. 11, lines 13-14). 

Moreover, while the Examiner has further stated on page 1 1 of the Exziminer's Answer that 
"Nothing within the specification described the 'separate use of either header size or body size" as 
asserted by the Applicant", the AppUcants again point the Examiner to page 10, Unes 10-19: 

The ALG header 210 comprises header data fields such as header format 
version 216, header size 218, expected header CRC 220, payload authentication 
signature 222, payload size 224, expected payload CRC 226, compatible hardware 
and software version famiUes 228 and 230, and other header data 212 such as 
compression parameters, copyright notices, and/or the date/time the payload was 
created, among other information. In one embodiment of the invention, many of 
these ALG header 210 components may be utilized as ALG file validity fields 214, 
which are used by the cable modem 130 to determine whether an upgraded or new 
ALG file 200 received by the cable modem 130 has been corrupted during file 
transfer, as well as compatible with the cable modem hardware and software. 

Further, the Examiner's position is INCONSISTENT. For example, on page 11, lines 4-6 
of the Examiner's Answer, the Examiner states that "[t]he comparison steps described in the 

specification merely states that the ALG size is determined from the header [Fig. 3, item 310; Pg. 
13, lines 4-9]". However, when citing the exact same portion of the Applicants' specification, the 
Examiner then states at page 11, Unes 7-10 of the Examiner's Answer that "[t]he ALG header and 



11 



CUSTOMER NO.: 24498 
Serial No.: 10/520,854 



PATENT 
PU020335 



ALG body sizes are used together as a single 'compatibility parameter' compared with a 
compatibility feature of the bi-directional device [See Fig. 3, item 310, 312; Pg. 13, lines 4-9]". 
While the Examiner is clearly inconsistent in his argument relating to the exact same pori:ion 

of the Applicants' disclosure , it is clear that the latter statement (regarding the ALG header and 
ALG body size being used together as a single compatibility parameter) is erroneous since file 
header size and file body size are described separately with spaces between their description and 
other parameters described therein between. Additionally, with respect to the same figure cited by 
the Examiner and argued inconsistently by the Examiner, the Applicants' specification discloses the 
following: "Method 300 comprises checking various parameters for compatibihty issues and loss of 
data during file transfer. It is noted that the types of parameters and the specific order shown in 
FIG. 3 for validating the various parameters are merely illustrative, and should not be construed as 
being so limiting." 

Moreover, the Examiner states that "[t]he Appellant states a larger header or body size may 
indicate the presence of a virus, yet the cited passage mentions nothing regarding the size of the 
header or body size field indicating the presence of a virus [See Appeal Brief, pg. 18, citing 
Specification Pg. 10, lines 9-11, 16-18]". However, the cited portion does in fact disclose a list of 
parameters that includes both the file header size and the file body size and continues to disclose 
that many of the header components may be utilized as file validity fields to determine whether a 
file has been corrupted. A file header size is clearly a header component and the inclusion of extra 
code in a header such as a virus would clearly increase the size of the header and thus would be 
ascertainable when compared to an expected size(s) that should be received (i.e., without a virus 
and corresponding virus code included therein). Hence, CRC fields by themselves are not only way 
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to ascertain the existence of corruption, as is readily known to those of ordinary skill in this and 
related arts. 

Further, Applicants do not even need to rely upon any inherency zirgument given the explicit 
disclosures in the instant application as cited above and below in support of the Applicants' 
position. 

In view of at least the preceding arguments, and the arguments as originally set forth in the 
Appeal Brief and reproduced herein below, it is respectfully asserted that the use of either one of the 
file header size and file body size, or both, are disclosed and supported by the AppUcEints' 
specification in accordance with 35 U.S.C. 1 12, first paragraph. 

The previous arguments from the Appeal Brief will now be reproduced for completeness. 

While significantly more detailed arguments follow, to put it aU the more succinctly while 
showing where this is going, we respectfully note the following: 

Page 11, lines 4-5 of the Applicants' specification describe the header size field. 

Page 11, lines 13-14 of the Applicants' specification describe the body size field. 

In between these descriptions of the header size field and the body size field, other 
parameters are described including the header expected CRC field and authentication signature 
field described. 

Hence, there is a space between the file header size and file body size when each are 
respectively described in the specification. 
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Also, in an exemplary listing of possible parameters on page 10, lines 23-28, other 
parameters (namely a header expected CRC and an authentication signature) £ire listed in 
between the listing of header size and body size. 

Thus, up to this point, they are described separately (and not jointly). 

Thereafter, with respect to FIG. 3, step 312 discloses the use of both file header size and 
file body size (clearly as a sum, although such word is not explicitly used, but instead the terms 
"ALG file 200 exceeds the capacity of the non- volatile memory 136" (where clearly the ALG file 
comprises the header and body, as explicitly disclosed at page 10, lines 1-2 of the Applicants' 
specification). That is, step 312 is disclosed at page 13, lines 4-9 as follows (emphasis added): 

At step 310, the ALG header size field 216 AND ALG body size field 
224 in the header 210 of the received ALG file 200 are checked . If at step 312, 
the ALG file 200 exceeds the capacity of the non-volatile memory 136 , then 
method 300 proceeds to step 350, where the ALG file 200 is rejected as discussed 
above. If at step 312, the ALG file 200 does not exceed the capacity of the non- 
volatile memory 136, then method 300 proceeds to step 314. 

Hence, the disclosure clearly discloses the separate use of either header size or body size, 
as well as the joint use (a sum) of both, in respective comparisons. 

Thus, the claims in issue are clearly supported by the Applicants' disclosure. 
The more detailed arguments will now follow. 
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Initially, the Applicants respectfully reproduce the following portion of MPEP §2163: 
"While there is no in haec verba requirement, newly added claim limitations must be supported in 
the specification through express, imphcit, or inherent disclosure." 

Support for the preceding limitation of Claims 1 and 16 identified by the Examiner may be 
found at least at page 9, lines 9-11 and 16-18; page 10, lines 10-28; page 1 1, lines 3-4 and lines 13- 
14; page 12, lines 6-9; and page 13, Unes 4-9 of the Applicants' specification. In particular, page 
10, lines 10-19 of the AppUcants' specification disclose the following (emphasis added): 

The ALG header 210 comprises header data fields such as header format 
version 216, header size 218 . expected header CRC 220, payload authentication 
signature 222, payload size 224 . expected payload CRC 226, compatible hardware 
and software version families 228 and 230, and other header data 212 such as 
compression parameters, copyright notices, and/or the date/time the payload was 
created, among other information. In one embodiment of the invention, mam of 
these ALG header 210 components may be utilized as ALG file validity fields 
214, which are used by the cable modem 130 to determine whether an upgraded or 
new ALG file 200 received by the cable modem 130 has been corrupted during file 
transfer, as well as compatible with the cable modem hardware and software. 

Thus, with respect to comparing the particular one compatibiUty parameter of said ALG 
file, at least the following approaches are at least one of expressly, implicitly, or 
inherently disclosed in the AppUcants' specification. As an example, the particular one 

compatibility parameter of said ALG file may be considered to be the header size or body size of 
the ALG file. In such a case, the header or body size field of said ALG file is compared with the 
available memory size (where the available memory size is a compatibility feature of said bi- 
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directional communications device) and also the header or body size field of said ALG file is 
compared with the feature of a received and authentic ALG file having a header or body size 
field(s) (and/or values therein) IN THE FIRST PLACE (as a header size field and body size field 
(and associated values) are expected in received and authentic ALG files, £ind their very absence is 
a likely indication of packet corruption). 

Thus, with respect to the first comparison described above (between the particular one 
compatibihty parameter of said ALG file and a compatibiUty feature of said bi-directional 
communications device), the header and/or body size field may be compared directly to the 
compatibility feature of said bi-directional communications device (e.g., an amount of available 
memory in said bidirectional communications device), since if either one does not fit in available 
memory, then certainly the entire ALG file wiU not fit in available memory. 

With respect to the second comparison described above (between the particular one 
compatibility parameter of said ALG file and the non-signature, non-code-error checking feature 
expected in received and authentic ALG files by said bi-directional communications device), the 
header or body size field may, in ONE IMPLEMENTATION, be compared to the non-signature, 
non-code-error checking feature of an ALG file having such a field(s) (or value(s) for that field(s)) 
in the first place as would be expected in received and authentic ALG files by said bi-directional 
communications device ( since, as noted above, an absence of such a field(s) is a strong indicator of 
data corruption ). Further, in ANOTHER IMPLEMENTATION, the header or body size field may 
be compared to the non-signature, non-code-error checking feature of an ALG file having a header 
or body size field with a particular value or within a range of values to determine whether the 
specified size, for example, exceeds size thresholds for expected ALG files that are received by said 
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bi-directional communications device and that are authentic. As an example, a larger sized body or 
larger sized header may indicate the presence of a virus such as a Trojein horse or a worm (see, e.g., 
Apphcants' specification, p. 10, Unes 9-11, disclosing "[t]he rules reflect poUcy considerations by 
an organization to provide security by prohibiting unwanted data from entering the organizations 
local area network/wide area network (LANAVLAN)."; and page 10, lines 16-18, disclosing 
"[a]dditional rules include restricting data packets that may be deemed harmful to the LAN and 
end-users, such as worms , as well as unauthorized persons (i.e., 'hackers') trying to infiltrate the 
LAN") (emphasis added). The above implementations are clearly disclosed, either expressly, 
implicitly, or inherently as required under MPEP §2163. This would seem particularly so in view 
of the Examiner's statement relating to the state of the art at the time of Applicants' invention, as 
set forth on page 5 of the Office Action dated January 8, 2009, where the Examiner stated (NO 
emphasis added by Applicants): 

Smith discloses of a method and system for providing protection from 
exploits to devices connected to a network by comparing the received file with a 
non- signature, non-code-error checking feature expected in received and authentic 
files [Para. 0065 and 0066; the size of the header or body of the file is examined 
to determine if they are longer then they should be] . It would have been obvious to 
one skilled in the ait at the time of the invention to verify the header or body 
length of a particular message to ensure that there is no executable code within the 
overflow buffers allotted for portions or all of a header or body of a file [Para. 
0026]. This allows the system to prevent improper access to data or unauthorized 
programs executed on the host computer [Para. 0026]. 
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Given the Examiner's preceding statement from page 5 of the pending Office Action 
relating to Smith, coupled at least witti tiie Applicants' disclosure and the following text from 
MPEP 2163, it would seem that the Examiner would agree with the Applicants' arguments as set 
forth above regarding the limitation in issue being supported by the Applicants' disclosure in 
compliance with 35 U.S.C. 112, first paragraph: 

Generally, there is an inverse coiTelation between the level of skill and 
knowledge in the art and the specificity of disclosure necessary to satisfy the written 
description requirement. Information which is well known in the art need not be 
described in detail in the specification. See, e.g., Hybritech, Inc. v. Monoclonal 
Antibodies, Inc., 802 F.2d 1367, 1379-80, 231 USPQ 81, 90 (Fed. Cir. 1986). 

It is to be noted that the Examiner has seemed to premise at least a portion of his 
argument on the following reasoning as set forth in the Response to Arguments section of the 
pending Office Action dated June 10, 2009 (emphasis added): 

The disclosure of the present application does not even suggest that the 
header or body size is compared to determine if there is anything unusual with the 
file itself. The present application discloses of comparing the header and/or body 
size of the incoming file only to determine if the ALG file fits within the non- 
volatile memory of the bi-directional device [See Fig. 3, item 312; Para. 0051 of 
present application] . There is no evidence or suggestion within the 
specification of comparing the header and/or body size of the incoming file to 
determine if a virus is present within the file. The disclosure merely suggests 
that the size comparison is made to determine if the file fits within the non- 
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volatile memory of the bi-directional device. There is nothing to suggest the 
inherency of any features of the Smith reference. 

To refute the Examiner's position, the following explicit disclosure is provided from the 
page 10, lines 9-11 and 16-18 (emphasis added): 

The rules reflect policy considerations by an organization to provide 
security by prohibiting unwanted data from entering the organizations local 
area network/wide area network (LANAVLAN). . . . Additional rules include 
restricting data packets that may be deemed harmful to the LAN and end- 
users, such as worms , as well as unauthorized persons (i.e., 'hackers') trying to 
infiltrate the LAN. 

Hence, it is clear that the Applicants' specification does, in fact, contemplate and 
explicitly disclose the prohibiting of unwanted data from entering the LANAVLAN such as 
worms (e.g., viruses), contrary to the Examiner's position and reading of the Applicants' 
specification. 

Accordingly, in view of the preceding, it is respectfully asserted that Claims 1 and 16 
satisfy 35 U.S.C. 112, first paragraph. Therefore, withdrawal of the rejection and allowance of 
Claims 1 and 16 is earnestly requested. 

C. Whether Claim 32 Satisfies 35 U.S.C. §112, First Paragraph 

As set forth in MPEP 2163.02: 
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The courts have described the essential question to be addressed in a 
description requirement issue in a variety of ways. An objective standard for 
determining compliance with the written description requirement is, "does the 
description clearly allow persons of ordinary skill in the art to recognize that he or 
she invented what is claimed." In re Gosteli, S12 F.2d 1008, 1012, 10 USPQ2d 
1614, 1618 (Fed. Ck. 1989). Under Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 
1563-64, 19 USPQ2d 1111, 1117 (Fed. Cir. 1991), to satisfy the written 
description requirement, an applicant must convey with reasonable clarity to those 
skilled in the art that, as of the filing date sought, he or she was in possession of 
the invention, and that the invention, in that context, is whatever is now claimed. 
The test for sufficiency of support in a parent application is whether the disclosure 
of the application relied upon "reasonably conveys to the artisan that the inventor 
had possession at that time of the later claimed subject matter." Ralston Purina 
Co. V. Far-Mar-Co., Inc., Ill F.2d 1570, 1575, 227 USPQ 177, 179 (Fed. Cir. 
1985) (quoting In re Kaslow, IQl F.2d 1366, 1375, 217 USPQ 1089, 1096 (Fed. 
Cir. 1983)). 

The Examiner rejected Claim 32 as failing to comply with the written description 
requirement. The Examiner contends that "wherein the particular one compatibility parameter is 
both capable of being directly compared and indirectly compared to the compatibility feature of 
said bi-directional communications device, wherein an indirect comparison involves the 
particular one compatibility parameter being included in a sum, and wherein the sum is capable 
of being directly compared to the compatibility feature of said bi-directional communications 
device." 

Hereinafter, it will be shown that Claim 32 does, in fact, comply with the written 
description requirement and, hence, satisfy 35 U.S.C. 112, first paragraph. 
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CI. Claim 32 

Per the limitation of Claim 32, the particular one compatibility pzirameter is both capable of 
being directly compared and indirectly compared to the compatibility feature of said bi-directional 
communications device, wherein an indirect comparison involves the particular one compatibility 
parameter being included in a sum, and wherein the sum is capable of being directly compared to 
the compatibihty feature of said bi-directional communications device. 

Initially, prior to reproducing the arguments submitted in the Appeal Brief, the Applicants 
will address the Examiner's comments in the Examiner's Answer . 

First, the Examiner is mischaracterizing the Applicants' argument when stating the 
following on page 10 of the Examiner's Answer (see also. Examiner's Answer, p. 13, Une 21-22 
and p. 14, Unes 5-6): 

The Appellant cites a portion of the specification which states that the "ALG 
header size field 216 AND ALG body size field 224 in tiie header 210 of tiie 
received ALG file 200 are checked" (emphasis added by AppUcants). The 
Appellant then asserts that this passage "clearly discloses the separate use of either 
header size of body size, as well as the joint use of both, in respective comparisons" 
[See Appeal Brief Pgs 15-16]. 

That is, the AppUcants did NOT simply base the preceding last sentence on solely the 
sentence before it. Rather, the entire first part of that argument in the Appeal Brief has been failed 
to be addressed or acknowledged by the Examiner, namely how both header size and body size are 
SEPARATELY DESCRIBED in other places in the specification (e.g., namely previously cited 
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page 10, lines 23-38, page 11, lines 4-5, and page 11, lines 13-14). For example, as noted in the 
first part of that argument, there is a space between the file header size £ind the file body size when 
each are respectively described in the specification, and other parameters are listed/described in that 
space. The separate description of the same, coupled with additional teachings that some 
(Applicants' specification, p. 10, lines 15-19) or all (AppUcants' specification, p. 10, lines 27-28) of 
the hsted parameters may be used, clearly discloses the use of one or both of the file header size and 
the file body size. 

Moreover, given the teachings of the present principles provided in the instant application , 
one of ordinary skiU in this and related arts, when contemplating the same, would realize that any 
one of the file body size and the file header size can be used by itself as a quick check of whether 
the overall ALG file size exceeds the memory capacity since if any one of the file header size or the 
file body size is greater than the memory capacity then clearly both will exceed that same memory 
capacity. Hence, the treating of the file header size and the file body size as separate parameters in 
the cited portions of the disclosure (e.g., AppUcants' specification, p. 10, lines 23-28, p. 1 1, lines 4- 
5, and p. ll,Unes 13-14). 

Moreover, while the Examiner has further stated on page 1 1 of the Examiner's Answer (see 
also. Examiner's Answer, p. 13, Une 21-22 and p. 14, Unes 5-6) that "Nothing within the 
specification described the 'separate use of either header size or body size' as asserted by the 
Applicant", the Applicants again point the Examiner to page 10, lines 10-19: 

The ALG header 210 comprises header data fields such as header format 
version 216, header size 218, expected header CRC 220, payload authentication 
signature 222, payload size 224, expected payload CRC 226, compatible hardware 
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and software version families 228 and 230, and other header data 212 such as 
compression parameters, copjright notices, and/or the date/time the payload was 
created, among other information. In one embodiment of the invention, many of 
these ALG header 210 components may be utiUzed as ALG file vziUdity fields 214, 
which are used by the cable modem 130 to determine whether an upgraded or new 
ALG file 200 received by the cable modem 130 has been corrupted during file 
tonsfer, as well as compatible with the cable modem hardware and software. 

Further, the Examiner's position is INCONSISTENT. For example, on page 11, lines 4-6 
of the Examiner's Answer, the Examiner states that "[t]he comparison steps described in the 
specification merely states that the ALG size is determined from the header [Fig. 3, item 310; Pg. 
13, lines 4-9]". However, when citing the exact same portion of the Applicants' specification, the 
Examiner then states at page 1 1 , lines 7-10 of the Examiner's Answer that "[t]he ALG header and 
ALG body sizes are used together as a single 'compatibiUty parameter' compared with a 
compatibility feature of the bi-directional device [See Fig. 3, item 310, 312; Pg. 13, lines 4-9]". 
While the Examiner is clearly inconsistent in his argument relating to the exact same portion 
of the Applicants' disclosure , it is clear that the latter statement (regarding the ALG header and 
ALG body size being used together as a single compatibility parameter) is erroneous since file 
header size and file body size are described separately with spaces between their description and 
other parameters described therein between. Additionally, with respect to the same figure cited by 
the Examiner and argued inconsistently by the Examiner, the Applicants' specification discloses the 
following: "Method 300 comprises checking various parameters for compatibility issues and loss of 
data during file transfer. It is noted that the types of parameters and the specific order shown in 
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FIG. 3 for validating the various parameters are merely iUustiative, and should not be construed as 
being so limiting." 

Moreover, the Examiner states that "[t]he Appellant states a larger header or body size may 
indicate the presence of a virus, yet the cited passage mentions nothing regarding the size of the 
header or body size field indicating the presence of a vims [See Appeal Brief, pg. 18, citing 
Specification Pg. 10, lines 9-11, 16-18]". However, the cited portion does in fact disclose a list of 
parameters that includes both the file header size and the file body size and continues to disclose 
that many of the header components may be utilized as file validity fields to determine whether a 
file has been corrupted. A file header size is clearly a header component and the inclusion of extra 
code in a header such as a virus would clearly increase the size of the header and thus would be 
ascertainable when compared to an expected size(s) that should be received (i.e., without a virus 
and corresponding virus code included therein). Hence, CRC fields by themselves are not only way 
to ascertain the existence of corruption, as is readily known to those of ordinary skill in this and 
related arts. 

Further, Applicants do not even need to rely upon any inherency argument given the exphcit 
disclosures in the instant application as cited above and below in support of the AppUcants' 
position. 

In view of at least the preceding arguments, and the arguments as originally set forth in the 
Appeal Brief and reproduced herein below, it is respectfully asserted that the use of either one of the 
file header size and file body size, or both, are disclosed and supported by the AppUcants' 
specification in accordance with 35 U.S.C. 112, first paragraph. 

The previous arguments from the Appeal Brief will now be reproduced for completeness. 
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While significantly more detailed arguments follow, to put it all the more succinctly while 
showing where this is going, we respectfully note the following: 

Page 11, lines 4-5 of the Applicants' specification describe the header size field. 

Page 11, lines 13-14 of the Applicants' specification describe the body size field. 

In between these descriptions of the header size field and the body size field, other 
parameters are described including the header expected CRC field and authentication signature 
field described. 

Hence, there is a space between the file header size and file body size when each £ire 
respectively described in the specification. 

Also, in an exemplary listing of possible parameters on page 10, lines 23-28, other 
parameters (namely a header expected CRC and an authentication signature) are listed in 
between the listing of header size and body size. 

Thus, up to this point, they are described separately (and not jointly). 

Thereafter, with respect to FIG. 3, step 312 discloses the use of both file header size and 
file body size (clearly as a sum, although such word is not explicitly used, but instead the terms 
"ALG file 200 exceeds the capacity of the non- volatile memory 136" (where clearly the ALG file 
comprises the header and body, as explicitly disclosed at page 10, lines 1-2 of the Applicants' 
specification)). That is, step 312 is disclosed at page 13, lines 4-9 as follows (emphasis added): 

At step 310, the ALG header size field 216 AND ALG body size field 
224 in the header 210 of the received ALG file 200 are checked . If at step 312, 
the ALG file 200 exceeds the capacity of the non- volatile memory 136 , then 
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method 300 proceeds to step 350, where the ALG file 200 is rejected as discussed 
above. If at step 312, the ALG file 200 does not exceed the capacity of the non- 
volatile memory 136, then method 300 proceeds to step 314. 

Hence, the disclosure clearly discloses the separate use of either header size or body size, 
as well as the joint use (a sum) of both, in respective comparisons. 

Thus, the claims in issue are clearly supported by the Applicants' disclosure. 
The more detailed arguments will now follow. 

Initially, the Applicants respectfully reproduce the following portion of MPEP §2163: 
"While there is no in haec verba requirement, newly added claim limitations must be supported in 
the specification through express, implicit, or inherent disclosure." 

Support for the preceding limitation of Claims 1 and 16 identified by the Examiner may be 
found at least at page 9, lines 9-11 and 16-18; page 10, lines 10-28; page 11, lines 3-4 and lines 13- 
14; page 12, lines 6-9; and page 13, lines 4-9 of the AppUcants' specification. In particular, page 
10, hnes 10-19 of the Applicants' specification disclose the following (emphasis added): 

The ALG header 210 comprises header data fields such as header format 
version 216, header size 218 , expected header CRC 220, payload authentication 
signature 222, payload size 224 . expected payload CRC 226, compatible hardware 
and software version families 228 and 230, and other header data 212 such as 
compression parameters, copyright notices, and/or the date/time the payload was 
created, among other information. In one embodiment of the invention, many of 
these ALG header 210 components may be utilized as ALG file validity fields 
214, which are used by the cable modem 130 to determine whether an upgraded or 
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new ALG file 200 received by the cable modem 130 has been corrupted during file 
transfer, as well as compatible with the cable modem hardware and software. 

Moreover, in particular, page 13, lines 4-8 of the AppUcants specification disclose the 
following (emphasis added): 

At step 310, the ALG header size field 216 and ALG body size field 224 
in the header 210 of the received ALG file 200 are checked . If at step 312, the 
ALG file 200 exceeds the capacity of the non-volatile memory 136 , then 
method 300 proceeds to step 350, where the ALG file 200 is rejected as discussed 
above. If at step 312, the ALG file 200 does not exceed the capacity of the non- 
volatile memory 136, then method 300 proceeds to step 314. 

Hence, while the Examiner has stated in the Response to Arguments section of the Office 
Action dated June 20, 2009 that "[t]he specification states that the ALG size (header or body size) 
is compared only once [FIG. 3, step 312] to determine if the ALG file fits within the non- volatile 
memory of the device (compatibility feature of the bi-directional device) [Fig. 3; Para. 0051]", it is 
clear that the Examiner has misread the AppUcants' specification with respect to step 312, as both 
the header AND body size are compared in total to the memory capacity of the non- volatile 
memory 136 in exemplary step 312. 

Moreover, page 12, lines 6-9 of the AppUcants specification further disclose the following: 

Method 300 comprises checking various parameters for compatibility 
issues and loss of data during file transfer. It is noted that the types of parameters 
and the specific order shown in FIG. 3 for validating the various parameters are 
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merely illustrative, and should not be construed as being so limiting. 

Hence, the particular one compatibility parameter of said ALG file may be considered to be 
the header size or body size of the ALG file, or both. Given that the Applicants explicitly disclose 
that many of the above mentioned parameters may be used as validity fields, it is clear that one or 
more of the header size or body size may be used. For example, in one implementation, the body 
size can simply be checked against the available memoiy as an efficient (i.e., without performing a 
summing operation) check as to whether the ALG file will fit into available memory. A more 
comprehensive check may sum both the body size and the header size and check the sum against 
the available memory. Such capabiUties and alternatives are clearly supported by the various cited 
portions of the Applicants' specification, particularly, when evaluated by one of ordinary skill in the 
art at the time of filing. 

Accordingly, in view of the preceding, it is respectfully asserted that Claim 32 satisfies 35 
U.S.C. 112, first paragraph. Therefore, withdrawal of the rejection and allowance of Claims 32 
is earnestly requested. 

D. Whether Claims 1, 2, 4, 12, 14, 16, 17, and 21-31 are Unpatentable Under 35 U.S.C. 
§103(a) With Respect to U.S. Patent No. 6,986,133 to O'Brien et al., in View of U.S. 
Patent Application No. 2002/0152399 to Smith 

"To establish prima facie obviousness of a claimed invention, all the claim limitations 

must be taught or suggested by the prior art" (MPEP §2143.03, citing In re Royka, 490 F.2d 981, 
180 USPQ 580 (CCPA 1974)). "If an independent claim is nonobvious under 35 U.S.C. 103, 
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then any claim depending therefrom is nonobvious" (MPEP §2143.03, citing In re Fine, 837 F.2d 
1071, 5 USPQ2d 1596 (Fed. Cir. 1988)). 

The Examiner rejected Claims 1, 2, 4, 12, 14, 16, 17, and 21-31 as being unpatentable 
over 6,986,133 to O'Brien et al. (hereinafter "O'Brien") in view of U.S. Patent Application No. 
2002/0152399 to Smith (hereinafter "Smith"). The Examiner contends that the cited 
combination shows all the limitations recited in Claims 1, 2, 4, 12, 14, 16, 17, £ind 21-31. 

O'Brien is directed to a "system and method for securely upgrading networked devices" 
(O'Brien, Title). In further detail, O'Brien discloses the following in his Abstract: 

A system (FIG. 1) for upgrading deployed networked devices 
(4,6,8,10,12,14,16). The devices are enabled with an installed agent (FIG. 2 left) 
that can identify and communicate with a server (22) running the upgrade 
program. When the appropriate conditions are met the server downloads the 
upgrade to the agent that then installs the upgrade onto the deployed device. The 
device is made capable of polling the server to see if an upgrade is available, or, in 
the alternative, the server can locate the device, queiy the state of the device and, 
when the appropriate predetermined conditions are met, download the upgrade to 
the device. 

Smith is directed to a "system and method for providing exploit protection for networks" 
(O'Brien, Title). In further detail. Smith discloses the following in his Abstract: 

A method and system for providing protection from exploits to devices 
connected to a network. The system and method include a component for 
determining whether an encapsulation has been applied to an attachment and 
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unencapsulating such encapsulated attachments, a component that performs at 
least one decompression of the attachment when the attachment is compressed, a 
component that determines whether a header, body, and/or attachment of a 
message includes an exploit, and a component that holds and optionally clezins 
messages that include exploits. A device that receives messages that are directed 
to the network employs the components above to provide exploit protection for at 
least one of the messages. 

It will be shown herein below that the limitations of Claims 1, 2, 4, 12, 14, 16, 17, 
and 21-31 reproduced herein are not shown in the cited combination, and that Claims 1, 2, 
4, 12, 14, 16, 17, and 21-31 should be aUowed. 

Dl. Claims 1, 2, 4, 12, 14, 16, 17, and 21-31 

Initially, it is respectfully pointed out to the Examiner that Claims 2, 4, 12, 14, and 21-25 
directly or indirectly depend from independent Claim 1, and Claims 17 and 26-31 directly or 
indirectly depend from independent Claim 16. Thus, Claims 2, 4, 12, 14, and 21-25 include all 
the limitations of Claim 1, and Claims 17 and 26-31 include all the limitations of Claim 16. 

It is respectfully asserted that that none of the cited references, either taken singly or in 
combination, teach or suggest the following step of/means for recited in Claims 1, 2, 4, 12, 14, 
16, 17, and 21-31 (with the following applicable to Claims 2, 4, 12, 14, and 21-25 by virtue of 
their respective dependencies from Claim 1, and with the following applicable to Claims 17 and 
26-31 by virtue of their respective dependencies from Claim 16): 

comparing, at the bi-directional communications device, a particular one 
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compatibility parameter of said ALG file with both a compatibility feature of said 
bi-directional communications device and a non-signature, non-code-error 
checking feature expected in received and authentic ALG files by said bi- 
directional communications device 

Initially, prior to reproducing the arguments submitted in the Appeal Brief, the Applicants 
will address the Examiner's comments in the Examiner's Answer . 

First, the Applicants note that the Examiner has reUed upon an alleged teaching in O'Brien 
that an upgrade policy includes a digital signature that is compared by the upgrade agent to 
authenticate and verify the upgrade file regarding the recited comparing of the particular one 
compatibility parameter of said ALG file with a compatibility feature of said bi-directional 
communications device and has further reUed upon an alleged teaching in Smith that the size of the 
header or body of the file is examined to determine if it longer than it should be regarding the 
recited comparing of the (SAME) particular one compatibility parameter of said ALG file with a 
non-signature, non-code-error checking feature expected in received and authentic ALG files by 
said bi-directional communications device. However, if the same particular one compatibihty 
parameter is being compared to both a compatibihty feature of said bi-directional communications 
device and a non-signature, non-code-error checking feature, the Examiner's proposed combination 
does not make sense and seems to contravene (teach away from) the specific claim limitations, 
since the claims explicitly recite "a non-signature , non-code-error checking feature" (emphasis 
added). That is, what would be the purpose or motivation for such an odd and apparently useless 
combination as proposed by the Examiner where a digital signature (as disclosed by O'Brien) is 
compared to a "non-signature, non-code-error checking feature". Thus, not only is any motivation 
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to combine as proposed by the Examiner lacking, but the proposed combination is contrary to the 
explicit claim limitations and further makes no sense. This is more fully argued in greater detail 
herein below in the originally provided arguments of the Appeal Brief and £ilso in the further 
argument below directed to the Examiner's Answer. 

The Examiner's new argument in the Examiner's Answer that "the term 'compatibility 
parameter' can be defined to include multiple elements which are all subparts of one 'compatibility' 
parameter" (see, e.g.. Examiner's Answer, p. 15, Unes 4-6) is misplaced and nonetheless fails to 
address the deficiency of the cited combination proposed by the Examiner where there is no 
usefulness or rationale for comparing a digital signature as disclosed by O'Brien against a non- 
signature, non-code-error checking feature as recited in the claims. For example, comparisons 
usually involve related items (e.g., apples to apples and NOT apples to oranges) and if one item is a 
digital signature and one is not, as proposed by the Examiner, then the rationale for performing such 
a comparison is completely lacking of purpose or rationale, and clearly does not correspond to the 
limitations recited in the pending claims. Given the preceding, the Examiner's statement on page 
17 of the Examiner's Answer that "O'Brien alone is sufficient to disclose the limitations of Claims 
1 and 16" seems erroneous and certainly does not cover the actual limitations recited in the pending 
claims but rather seems to teach away from the same. 

With respect to Claims 4, 23, and 27, the Examiner has stated on page 17 of the Examiner's 
Answer that the "particular one compatibility parameter" is defined as "comprises one of a header 
size of said ALG file and a body size of said ALG file". The Examiner then continued that "[t]he 
transitional term 'comprising' is inclusive or open-ended and does not exclude additional, unrecited 
elements or method steps" (see, e.g.. Examiner's Answer, p. 17, hues 1-4). However, while the 
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Examiner immediately there before cited a plurality of alleged parameters disclosed in the cited 
references, none made any sense in the proposed combinations asserted by the Examiner (i.e., none 
seemed to be items that would rationally be compared to each other and where such a comparison 
would prove useful, such as the above mentioned seemingly un-useful comparison proposed by the 
Examiner involving comparing a digital signature as per O'Brien with a non-signature, non-code- 
error checking feature as recited in the pending claims), since as noted more fully herein below, the 
pending claims essentially require a comparison of 1 item (particular one compatibility pzirameter of 
said ALG file) with item 2 (a compatibility feature of said bi-directional communications device) 
AND with item 3 (a non-signature, non-code-error checking feature expected in received and 
authentic ALG files by said bi-directional communications device). 

With respect to Claims 24 and 30, the Examiner's inconsistent use of the cited references is 
improper, unfair and stiU does not anticipate or render obvious the pending claim limitations as 
argued more fully herein below. Moreover, despite the Examiner's allegation to the contrary, using 
a digital signature from O'Brien to reject, for example. Claims 1 and 16, while later using a 
checksum from O'Brien to reject Claims 24 and 30, where the digital signature and the checksum 
are used interchangeably for the same claim element is an inconsistent use. Moreover, the 
proposed combination involving the checksum also fails to prove useful in the required comparing 
necessary per the recited claim limitations (i.e., item 1 compared to both item 2 and item 3) and 
hence, lacks a motivation to combine. 

Hence, the Examiner's further arguments in the Examiner's Answer still do not show that 
the pending claim hmitations are anticipated or rendered obvious by the cited references. 

The previous arguments from the Appeal Brief wiU now be reproduced for completeness. 
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It is to be further noted that Claims 1, 2, 4, 12, 14, 16, 17, and 21-31 require by their 
respective explicit hmitations that the particular one compatibility pzirameter of said ALG file 
(hereinafter interchangeably referred to as "item 1" for the sake of illustration) is compared with 
both a compatibility feature of said bi-directional communications device (hereinafter 
interchangeably referred to as "item 2" for the sake of illustration) and a non-signature, non-code- 
error checking feature expected in received and authentic ALG files by said bi-directional 
communications device (hereinafter interchangeably referred to as "item 3" for the sake of 
illustration). Thus, per Claims 1, 2, 4, 12, 14, 16, 17, and 21-31, item 1 is compared with both item 
2 and item 3. That is, the same item 1 is compared to both item 2 and item 3. 

In contrast, in setting forth the rejection, the Examiner has set forth the following reasoning 
with respect to items 1 and 2 (first comparison) above, relying upon O'Brien: "upgrade poUcy 
includes a digital signature that is compared by the upgrade agent to authenticate and verify the 
upgrade file" (Office Action, p. 10). 

However, in further setting forth the rejection, the Examiner has set forth the following 
reasoning with respect to items 1 and 3 (second comparison) above, relying upon Smith: "Para. 
0065 and 0066; the size of the header or body of the file is examined to determine if they are 
longer then they should be" (Office Action, p. 11). 

Thus, according to the Examiner's rejection, a comparison of digital signatures per 
O'Brien and a comparison of header (or file body) sizes per Smith cover all the above reproduced 
comparing recited in the pending claims. However, as per the explicit claim limitations, if the 
SAME particular one compatibility parameter is compared to BOTH a compatibility feature of 
said bi-directional conmiunications device and a non-signature, non-code-error checking feature 
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expected in received and authentic ALG files by said bi-directional communications device, 
THEN THE EXAMINER'S PROPOSED COMBINATION IS CLEARLY DEFICIENT ON ITS 
FACE SINCE THE CLAIM EXPLICITLY EXCLUDES SIGNATURES FROM ITEM 3, AND 
SINCE ITEM 3 IS COMPARED TO ITEM 1, ITEM 1 CAN NEVER BE A SIGNATURE. That 
is, since item 1 (a particular one compatibility parameter of said ALG file) is compared to both 
item 2 (compatibility feature of said bi-directional communications device) £ind item 3 (a non- 
signature, non-code-error checking feature expected in received and authentic ALG files by said 
bi-directional communications device), then item 1 can never relate to a signature since that 
would mean that item 3 is a signature (in order to compare apples to apples, and not apples to 
oranges) which is explicitly prohibited (a non-sisnature , non-code-error checking feature 
expected in received and authentic ALG files by said bi-directional communications device) by 
the claim language. 

Hence, initially the Examiner cited a digital signature from O'Brien as corresponding to 
the particular one compatibility parameter of said ALG file, and then cited a header or file body 
size as corresponding to the particular one compatibility parameter of said ALG file. Clearly, 
while the above reproduced claim limitations call for the SAME particular ONE compatibility 
parameter of said ALG file (to be compared to BOTH a compatibility feature of said bi- 
directional communications device and a non- signature, non-code-error checking feature 
expected in received and authentic ALG files by said bi-directional communications device), the 
Examiner's rejection uses a digital signature and a (header or file body) size as corresponding 
to the particular ONE compatibility parameter of said ALG file which clearly is incorrect. 



35 



CUSTOMER NO.: 24498 
Serial No.: 10/520,854 



PATENT 
PU020335 



Moreover, while the claims recite, inter alia, "comparing, at the bi-directional 
communications device, a particular one compatibility parameter of sdid ALG file with both a 
compatibility feature of said bi-directional communications device. . .", the Examiner has equated 
a digital signature comparison in O'Brien to the same. However, it is respectfully pointed out to 
the Examiner that a signature (as disclosed by O'Brien) relates to a file itself and has nothing to 
do with a compatibility feature of the bi-directional communications device . 

Hence, it is clear from the onset that the Examiner has failed to set forth a prima facie 
rejection of the claims under 35 U.S.C. 103(a), as the Examiner has failed to show each £ind 
every element recited in the claims. 

Hence, the cited combination fails to teach or suggest the above recited limitations of 
Claims 1, 2, 4, 12, 14, 16, 17, and 21-31. 

Accordingly, Claims 1, 2, 4, 12, 14, 16, 17, and 21-31 are patentably distinct and non- 
obvious over the cited combination for at least the reasons set forth above. Therefore, 
withdrawal of the rejection and allowance of Claims 1, 2, 4, 12, 14, 16, 17, and 21-31 is earnestly 
requested. 

D2. Claims 24 and 30 

It is respectfully asserted that that none of the cited references, either taken singly or in 
combination, teach or suggest the following limitations recited in Claims 24 and 30: 

wherein a value of the particular one compatibility parameter of said ALG 
file is added to a value of another particular one compatibility parameter of said 
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ALG file as a sum that is compared to a value of the compatibility feature of said 
bi-directional communications device. 

Initially, prior to reproducing the arguments submitted in the Appeal Brief, the Applicants 
will address the Examiner's comments in the Examiner's Answer . 

With respect to Claims 24 and 30, the Examiner's inconsistent use of the cited references is 
improper, unfair and still does not anticipate or render obvious the pending claim limitations as 
argued more fully herein below. Moreover, despite the Examiner's allegation to the contrary, using 
a digital signature from O'Brien to reject, for example. Claims 1 and 16, while later using a 
checksum from O'Brien to reject Claims 24 and 30, where the digital signature and the checksum 
are used interchangeably for the same claim element is an inconsistent use. Moreover, the 
proposed combination involving the checksum also fails to prove useful in the required comparing 
necessary per the recited claim Umitations (i.e., item 1 compared to both item 2 and item 3) and 
hence, lacks a motivation to combine. 

Hence, the Examiner's further arguments in the Examiner's Answer still do not show that 
the pending claim limitations are anticipated or rendered obvious by the cited references. 

The previous arguments from the Appeal Brief will now be reproduced for completeness. 

For example, the Examiner has cited column 7, lines 15-18 of O'Brien, while providing the 
following reasoning on page 7 of the Office Action dated January 8, 2009 and pages 12-13 of the 
Office Action dated June 10, 2009: "the upgrade agent performs a comparison for each chunk of the 
upgrade with the appropriate checksum to determine if the file is corrupt". First, the Examiner's 
use of these references is completely INCONSISTENT and quite unfair in that the Examiner's is 
equating a plurahty of different elements to the same element that is recited in multiple claims. For 
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example, with respect to Claims 1 and 16 (from which Claims 24 and 30 respectively depend), the 
Examiner equated a signature comparison disclosed in O'Brien with recited item 1 (i.e., "particular 
one compatibihty parameter of said ALG file") and item 2 (i.e., "compatibiUty feature of said bi- 
directional communications device"), and the header or body length of a particular message 
disclosed in Smith to recited item 1 and item 3 (i.e., "non-signature, non-code-error checking 
feature expected in received and authentic ALG files by said bi-directional communications 
device"). However, in rejecting Claims 24 and 30 on page 7 of the Office Action dated January 8, 
2009, the cited reasoning of the "upgrade agent performs a comparison for each chunk of the 
upgrade with the appropriate checksum to determine if the file is corrupt" relates to none of the 
previously correlated items, namely the signature comparison disclosed in O'Brien, nor the header 
or body length of a particular message disclosed in Smith. Further, item 3 as explicitly recited in 
the claims is "non-signature, non-code-error checking feature expected in received and authentic 
ALG files by said bi-directional communications device" (emphasis added). Hence, the citation of 
"an appropriate checksum" from Smith by the Examiner is exphcitiy prohibited by the recited claim 
language and, hence, can never correspond to the same, thus showing that the Examiner has clearly 
failed to set forth a prima facie rejection as required under 35 U.S.C. 103(a). Moreover, Claims 24 
and 30 recite that a value of the particular one compatibility parameter of said ALG file is added to 
a value of another particular one compatibiUty parameter of said ALG file as a sum that is 
compared to a value of the compatibility feature of said bi-directional communications device. For 
example, in the Examiner's reasoning, the Examiner has provided no correlation to the 
compatibihty feature of said bi-directional communications device. 
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Hence, the cited combination fails to teach or suggest the above recited limitations of 
Claims 24 and 30. 

Accordingly, Claims 24 and 30 are patentably distinct and non-obvious over the cited 
combination for at least the reasons set forth above. Therefore, withdrawal of the rejection and 
allowance of Claims 24 and 30 is earnestly requested. 



E. Whether Claims 11 and 18 are Unpatentable Under 35 U.S.C. §103(a) With Respect 
to U.S. Patent No. 6,986,133 to O'Brien et al., in View of U.S. Patent Application No. 
2002/0152399 to Smith, and Further in View of U.S. Patent No. 6,665,752 to Bernath 

"To establish prima facie obviousness of a claimed invention, all the claim limitations 
must be taught or suggested by the prior art" (MPEP §2143.03, citing In re Royka, 490 F.2d 981, 
180 USPQ 580 (CCPA 1974)). "If an independent claim is nonobvious under 35 U.S.C. 103, 
then any claim depending therefrom is nonobvious" (MPEP §2143.03, citing In re Fine, 837 F.2d 
1071, 5 USPQ2d 1596 (Fed. Cir. 1988)). 

The Examiner rejected Claims 11 and 18 as being unpatentable over 6,986,133 to 
O'Brien et al. (hereinafter "O'Brien") in view of U.S. Patent Application No. 2002/0152399 to 
Smith (hereinafter "Smith") and further in view of U.S. Patent No. 6,666,752 to Bernath 
(hereinafter "Bernath"). The Examiner contends that the cited combination shows all the 
limitations recited in Claims 11 and 18. 

O'Brien is directed to a "system and method for securely upgrading networked devices" 
(O'Brien, Title). In further detail, O'Brien discloses the following in his Abstract: 
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A system (FIG. 1) for upgrading deployed networked devices 
(4,6,8,10,12,14,16). The devices are enabled with an installed agent (FIG. 2 left) 
that can identify and communicate with a server (22) running the upgrade 
program. When the appropriate conditions are met the server downloads the 
upgrade to the agent that then installs the upgrade onto the deployed device. The 
device is made capable of polling the server to see if an upgrade is available, or, in 
the alternative, the sei-ver can locate the device, query the state of the device and, 
when the appropriate predetermined conditions are met, download the upgrade to 
the device. 

Smith is directed to a "system and method for providing exploit protection for networks" 
(O'Brien, Title). In further detail. Smith discloses the following in his Abstract: 

A method and system for providing protection from exploits to devices 
connected to a network. The system and method include a component for 
determining whether an encapsulation has been applied to an attachment and 
unencapsulating such encapsulated attachments, a component that performs at 
least one decompression of the attachment when the attachment is compressed, a 
component that determines whether a header, body, and/or attachment of a 
message includes an exploit, and a component that holds and optionally cleans 
messages that include exploits. A device that receives messages that are directed 
to the network employs the components above to provide exploit protection for at 
least one of the messages. 

Bemath is directed to an "interrupt driven interface coupUng a programmable media access 
controller and a process controller" (Bemath, preamble). In further detail, Bemath discloses the 
following in his Abstract: 
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An interrupt driven interface coupling a programmable media access 
controller (MAC) and a process controller. The interrupt driven interface is 
operable within a cable modem system. The specification by which the cable 
modem operates to transfer data between the programmable media access 
controller (MAC) and the control processor is loaded into a memory location 
within the system, and the physical system is operable to provide for backward 
compatibility, in that, the addition of new messages and the deletion of old 
messages within the specification is performed via software upgrade. The 
necessity of a re-design and re-fabrication of the programmable media access 
controller (MAC) and the control processor, and the interface between them is 
completely obviated by the present invention. 

It will be shown herein below that the Umitations of Claims 1 1 and 18 reproduced herein 
are not shown in the cited combination, and that Claims 1 1 and 18 should be allowed. 

El. Claims 11 and 18 

Initially, it is respectfully pointed out to the Examiner that Claims 1 1 and 18 directly 
depend from independent Claims 1 and 16, respectively. Thus, Claims 11 and 18 include all the 
limitations of Claims 1 and 16, respectively. 

It is respectfully asserted that that none of the cited references, either taken singly or in 
combination, teach or suggest the following limitations recited in Claims 11 and 18 (with the 
following applicable to Claims 11 and 18 by virtue of their respective dependencies from Claims 
1 and 16): 
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comparing, at the bi-directional communications device, a particular one 
compatibility parameter of said ALG file with both a compatibility feature of said 
bi-directional communications device and a non-signature, non-code-error 
checking feature expected in received and authentic ALG files by sdd bi- 
directional communications device 

Initially, prior to reproducing the arguments submitted in the Appeal Brief, the Applicants 
will address the Examiner's comments in the Examiner's Answer . 

First, the Applicants note that the Examiner has relied upon an alleged teaching in O'Brien 
that an upgrade policy includes a digital signature that is compared by the upgrade agent to 
authenticate and verify the upgrade file regarding the recited comparing of the particular one 
compatibiUty parameter of said ALG file with a compatibility feature of said bi-directional 
communications device and has further relied upon an alleged teaching in Smith that the size of the 
header or body of the file is examined to determine if it longer than it should be regarding the 
recited comparing of the (SAME) particular one compatibiUty parameter of said ALG file with a 
non-signature, non-code-error checking feature expected in received and authentic ALG files by 
said bi-directional communications device. However, if the same particular one compatibiUty 
parameter is being compared to both a compatibility feature of said bi-directional communications 
device and a non- signature, non-code-error checking feature, the Examiner's proposed combination 
does not make sense and seems to contravene (teach away from) the specific claim limitations, 
since the claims explicitly recite "a non-signature , non-code-error checking feature" (emphasis 
added). That is, what would be the purpose or motivation for such an odd and apparently useless 
combination as proposed by the Examiner where a digital signature (as disclosed by O'Brien) is 
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compared to a "non-signature, non-code-error checking feature". Thus, not only is any motivation 
to combine as proposed by the Examiner lacking, but the proposed combination is contrary to the 
exphcit claim Umitations and further makes no sense. This is more fully argued in greater detail 
herein below in the originally provided arguments of the Appeal Brief and also in the further 
argument below directed to the Examiner's Answer. 

The Examiner's new argument in the Examiner's Answer that "the term 'compatibiUty 
parameter' can be defined to include multiple elements which are aU subparts of one 'compatibiUty' 
parameter" (see, e.g., Examiner's Answer, p. 15, Unes 4-6) is misplaced and nonetheless fziils to 
address the deficiency of the cited combination proposed by the Examiner where there is no 
usefulness or rationale for comparing a digital signature as disclosed by O'Brien against a non- 
signature, non-code-error checking feature as recited in the claims. For example, comparisons 
usually involve related items (e.g., apples to apples and NOT apples to oranges) and if one item is a 
digital signature and one is not, as proposed by the Examiner, then the rationale for performing such 
a comparison is completely lacking of purpose or rationale, and clearly does not correspond to the 
Umitations recited in the pending claims. Given the preceding, the Examiner's statement on page 
17 of the Examiner's Answer that "O'Brien alone is sufficient to disclose the limitations of Claims 
1 and 16" seems erroneous and certainly does not cover the actual limitations recited in the pending 
claims but rather seems to teach away from the same. 

Hence, the Examiner's further arguments in the Examiner's Answer still do not show that 
the pending claim Umitations are anticipated or rendered obvious by the cited references. 

The previous arguments from the Appeal Brief wiU now be reproduced for completeness. 
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It is to be further noted that Claims 11 and 18 require by their respective expUcit limitations 
that the particular one compatibiUty parameter of sdd ALG file (hereinafter interchangeably 
referred to as "item 1" for the sake of illustration) is compared with both a compatibiUty feature of 
said bi-directional communications device (hereinafter interchangeably referred to as "item 2" for 
the sake of illustration) and a non-signature, non-code-error checking feature expected in received 
and authentic ALG files by said bi-directional communications device (hereinafter interchangeably 
referred to as "item 3" for the sake of illustration). Thus, per Claims 11 and 18, item 1 is compared 
with both item 2 and item 3. That is, the same item 1 is compared to both item 2 and item 3. 

In contrast, in setting forth the rejection, the Examiner has set forth the following reasoning 
with respect to items 1 and 2 (first comparison) above, relying upon O'Brien: "upgrade policy 
includes a digital signature that is compared by the upgrade agent to authenticate and verify the 
upgrade file" (Office Action, p. 10). 

However, in further setting forth the rejection, the Examiner has set forth the following 
reasoning with respect to items 1 and 3 (second comparison) above, relying upon Smith: "Para. 
0065 and 0066; the size of the header or body of the file is examined to determine if they are 
longer then they should be" (Office Action, p. 11). 

Thus, according to the Examiner's rejection, a comparison of digital signatures per 
O'Brien and a comparison of header (or file body) sizes per Smith cover all the above reproduced 
comparing recited in the pending claims. However, if the SAME particular one compatibility 
parameter is compared to BOTH a compatibility feature of said bi-directional communications 
device and a non- signature, non-code-error checking feature expected in received and authentic 
ALG files by said bi-directional contmiunications device, THEN THE EXAMINER'S 
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PROPOSED COMBINATION IS CLEARLY DEHCIENT ON ITS FACE SINCE THE CLAIM 
EXPLICITLY EXCLUDES SIGNATURES FROM ITEM 3, AND SINCE ITEM 3 IS 
COMPARED TO ITEM 1, ITEM 1 CAN NEVER BE A SIGNATURE. That is, since item 1 (a 
particular one compatibility parameter of said ALG file) is compared to both item 2 
(compatibility feature of said bi-directional communications device) and item 3 (a non-signature, 
non-code-error checking feature expected in received and authentic ALG files by said bi- 
directional communications device), then item 1 can never relate to a signature since that would 
mean that item 3 is a signature (in order to compare apples to apples, and not apples to oranges) 
which is explicitly prohibited (a non-sienature , non-code-error checking feature expected in 
received and authentic ALG files by said bi-directional communications device) by the cMm 



Hence, initially the Examiner cited a digital signature from O'Brien as corresponding to 
the particular one compatibility parameter of said ALG file, and then cited a header or file body 
size as corresponding to the particular one compatibility parameter of said ALG file. Clearly, 
while the above reproduced claim limitations call for the SAME particular ONE compatibility 
parameter of said ALG file (to be compared to BOTH a compatibility feature of said bi- 
directional communications device and a non- signature, non-code-error checking feature 
expected in received and authentic ALG files by said bi-directional communications device), the 
Examiner's rejection uses a digital signature and a (header or file body) size as corresponding 
to the particular ONE compatibility parameter of said ALG file which clearly is incorrect. 

Moreover, while the claims recite, inter alia, "comparing, at the bi-directional 
communications device, a particular one compatibility parameter of said ALG file with both a 



language. 
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compatibility feature of said bi-directional communications device. . .", the Examiner has equated 
a digital signature comparison in O'Brien to the szime. However, it is respectfully pointed out to 
the Examiner that a signature (as disclosed by O'Brien) relates to a file itself zind has nothing to 
do with a compatibility feature of the bi-directional communications device . 

Hence, it is clear from the onset that the Examiner has failed to set forth a prima facie 
rejection of the claims under 35 U.S.C. 103(a), as the Examiner has failed to show each and 
every element recited in the claims. 

Hence, the cited combination fails to teach or suggest the above recited limitations of 
Claims 11 and 18. 

Accordingly, Claims 11 and 18 are paten tably distinct and non-obvious over the cited 
combination for at least the reasons set forth above. Therefore, withdrawal of the rejection and 
allowance of Claims 11 and 18 is earnestly requested. 

F. Whether Claim 13 is Unpatentable Under 35 U.S.C. §103(a) With Respect to U.S. 
Patent No. 6,986,133 to O'Brien et al., in View of U.S. Patent Application No. 
2002/0152399 to Smith, and Further in View of U.S. Patent No. 6,031,830 to Cowan 

"To establish prima facie obviousness of a claimed invention, all the claim limitations 
must be taught or suggested by the prior art" (MPEP §2143.03, citing In re Royka, 490 F.2d 981, 
180 USPQ 580 (CCPA 1974)). "If an independent claim is nonobvious under 35 U.S.C. 103, 
then any claim depending therefrom is nonobvious" (MPEP §2143.03, citing In re Fine, 837 F.2d 
1071, 5 USPQ2d 1596 (Fed. Ck. 1988)). 

The Examiner rejected Claim 13 as being unpatentable over 6,986,133 to O'Brien et al. 
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(hereinafter "O'Brien") in view of U.S. Patent Application No. 2002/0152399 to Smith 
(hereinafter "Smith") and further in view of U.S. Patent No. 6,031,830 to Cowan (hereinafter 
"Cowan"). The Examiner contends that the cited combination shows all the limitations recited in 

Claim 13. 

O'Brien is directed to a "system and method for securely upgrading networked devices" 
(O'Brien, Tide). In further detail, O'Brien discloses the following in his Abstract: 

A system (FIG. 1) for upgrading deployed networked devices 
(4,6,8,10,12,14,16). The devices are enabled with an installed agent (FIG. 2 left) 
that can identify and communicate with a server (22) running the upgrade 
program. When the appropriate conditions are met the server downloads the 
upgrade to the agent that then installs the upgrade onto the deployed device. The 
device is made capable of polling the server to see if an upgrade is available, or, in 
the alternative, the server can locate the device, query the state of the device and, 
when the appropriate predetermined conditions are met, download the upgrade to 
the device. 

Smith is directed to a "system and method for providing exploit protection for networks" 
(O'Brien, Tide). In further detail. Smith discloses the following in his Abstract: 

A method and system for providing protection from exploits to devices 

connected to a network. The system and method include a component for 
determining whether an encapsulation has been applied to an attachment and 
unencapsulating such encapsulated attachments, a component that performs at 
least one decompression of the attachment when the attachment is compressed, a 
component that determines whether a header, body, and/or attachment of a 
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message includes an exploit, and a component that holds and optionally cleans 
messages that include exploits. A device that receives messages that are directed 
to the network employs the components above to provide exploit protection for at 
least one of the messages. 

Cowan is directed to "wireless software upgrades with version control" (Cowan, preamble). 
In further detail. Cowan discloses the following in his Abstract: 

A wireless communication system which includes a system backbone; a 
host computer coupled to the system backbone; at least one base station coupled 
to the system backbone, the at least one base station including a base station 
transceiver for communicating wirelessly with mobile devices within the system; 
at least one mobile device having a mobile device transceiver for communicating 
wirelessly with the host computer on the system backbone via the at least one base 
station; and wherein the host computer and the at least one mobile device are 
operatively configured to communicate selectively mobile device operating 
software therebetween based on an initial comparison in accordance with a 
predetermined criteria indicative of whether communication of mobile operating 
software therebetween is appropriate. 

It will be shown herein below that the Umitations of Claim 13 reproduced herein are not 
shown in the cited combination, and that Claim 13 should be allowed. 

Fl. Claim 13 

Initially, it is respectfully pointed out to the Examiner that Claim 13 directly depends 
from independent Claim 1. Thus, Claim 13 includes all the limitations of Claim 1. 
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It is respectfully asserted that that none of the cited references, either taken singly or in 
combination, teach or suggest the following limitations recited in CMm 13 (with the following 
applicable to Claim 13 by virtue of its respective dependency from CMm 1): 

comparing, at the bi-directional communications device, a particular one 
compatibility parameter of said ALG file with both a compatibility feature of said 
bi-directional communications device and a non-signature, non-code-error 
checking feature expected in received and authentic ALG files by said bi- 
directional communications device 

Initially, prior to reproducing the arguments submitted in the Appeal Brief, the Applicants 
will address the Examiner's comments in the Examiner's Answer . 

First, the Applicants note that the Examiner has relied upon an alleged teaching in O'Brien 
that an upgrade policy includes a digital signature that is compared by the upgrade agent to 
authenticate and verify the upgrade file regarding the recited comparing of the particular one 
compatibiUty parameter of said ALG file with a compatibility feature of said bi-directional 
conmiunications device and has further reUed upon an alleged teaching in Smith that the size of the 
header or body of the file is examined to determine if it longer than it should be regarding the 
recited comparing of the (SAME) particular one compatibiUty parameter of said ALG file with a 
non-signature, non-code-error checking feature expected in received and authentic ALG files by 
said bi-directional communications device. However, if the same particular one compatibiUty 
parameter is being compared to both a compatibiUty feature of said bi-directional communications 
device and a non-signature, non-code-error checking feature, the Examiner's proposed combination 
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does not make sense and seems to contravene (teach away from) the specific claim Umitations, 
since the claims exphcitly recite "a non-signature , non-code-error checking feature" (emphasis 
added). That is, what would be the purpose or motivation for such an odd and apparently useless 
combination as proposed by the Examiner where a digital signature (as disclosed by O'Brien) is 
compared to a "non- signature, non-code-error checking feature". Thus, not only is any motivation 
to combine as proposed by the Examiner lacking, but the proposed combination is contrary to the 
explicit claim limitations and further makes no sense. This is more fuUy argued in greater detail 
herein below in the originally provided arguments of the Appeal Brief and also in the further 
argument below directed to the Examiner's Answer. 

The Examiner's new argument in the Examiner's Answer that "the term 'compatibility 
parameter' can be defined to include multiple elements which are all subparts of one 'compatibility' 
parameter" (see, e.g.. Examiner's Answer, p. 15, Unes 4-6) is misplaced and nonetheless fails to 
address the deficiency of the cited combination proposed by the Examiner where there is no 
usefulness or rationale for comparing a digital signature as disclosed by O'Brien against a non- 
signature, non-code-error checking feature as recited in the claims. For example, comparisons 
usually involve related items (e.g., apples to apples and NOT apples to oranges) and if one item is a 
digital signature and one is not, as proposed by the Examiner, then the rationale for performing such 
a comparison is completely lacking of purpose or rationale, and clearly does not correspond to the 
limitations recited in the pending claims. Given the preceding, the Examiner's statement on page 
17 of the Examiner's Answer that "O'Brien alone is sufficient to disclose the Umitations of Claims 
1 and 16" seems erroneous and certainly does not cover the actual Umitations recited in the pending 
claims but rather seems to teach away from the same. 
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Hence, the Examiner's further arguments in the Examiner's Answer still do not show that 
the pending claim hmitations are anticipated or rendered obvious by the cited references. 

The previous arguments from the Appeal Brief wiU now be reproduced for completeness. 

It is to be further noted that Claim 13 requires by its respective explicit limitations that the 
particular one compatibility parameter of said ALG file (hereinafter interchangeably referred to as 
"item 1" for the sake of illustration) is compared with both a compatibility feature of said bi- 
directional communications device (hereinafter interchangeably referred to as "item 2" for the sake 
of illustration) and a non-signature, non-code-error checking feature expected in received and 
authentic ALG files by said bi-directional communications device (hereinafter interchangeably 
referred to as "item 3" for the sake of illustration). Thus, per Claim 13, item 1 is compared with 
both item 2 and item 3. That is, the same item 1 is compared to both item 2 and item 3. 

In contrast, in setting forth the rejection, the Examiner has set forth the following reasoning 
with respect to items 1 and 2 (first comparison) above, relying upon O'Brien: "upgrade policy 
includes a digital signature that is compared by the upgrade agent to authenticate and verify the 
upgrade file" (Office Action, p. 10). 

However, in further setting forth the rejection, the Examiner has set forth the following 
reasoning with respect to items 1 and 3 (second comparison) above, relying upon Smith: "Para. 
0065 and 0066; the size of the header or body of the file is examined to determine if they are 
longer then they should be" (Office Action, p. 11). 

Thus, according to the Examiner's rejection, a comparison of digital signatures per 
O'Brien and a comparison of header (or file body) sizes per Smith cover all the above reproduced 
comparing recited in the pending claims. However, if the SAME particular one compatibility 
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parameter is compared to BOTH a compatibility feature of said bi-directional communications 
device and a non- signature, non-code-error checking feature expected in received and authentic 
ALG files by said bi-directional communications device, THEN THE EXAMINER'S 
PROPOSED COMBINATION IS CLEARLY DEFICIENT ON ITS FACE SINCE THE CLAIM 
EXPLICITLY EXCLUDES SIGNATURES FROM ITEM 3, AND SINCE ITEM 3 IS 
COMPARED TO ITEM 1, ITEM 1 CAN NEVER BE A SIGNATURE. That is, since item 1 (a 
particular one compatibility parameter of said ALG file) is compared to both item 2 
(compatibility feature of said bi-directional communications device) and item 3 (a non-signature, 
non-code-error checking feature expected in received and authentic ALG files by said bi- 
directional communications device), then item 1 can never relate to a signature since that would 
mean that item 3 is a signature (in order to compare apples to apples, and not apples to oranges) 
which is explicitly prohibited (a non-sienature , non-code-error checking feature expected in 
received and authentic ALG files by said bi-directional communications device) by the claim 



Hence, initially the Examiner cited a digital signature from O'Brien as corresponding to 
the particular one compatibility parameter of said ALG file, and then cited a header or file body 
size as corresponding to the particular one compatibility parameter of said ALG file. Clearly, 
while the above reproduced claim limitations call for the SAME particular ONE compatibility 
parameter of said ALG file (to be compared to BOTH a compatibility feature of said bi- 
directional conmiunications device and a non- signature, non-code-error checking feature 
expected in received and authentic ALG files by said bi-directional communications device), the 
Examiner's rejection uses a digital signature and a (header or file body) size as corresponding 



language. 
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to the particular ONE compatibility parameter of said ALG file which clearly is incorrect. 

Moreover, while the claims recite, inter alia, "comparing, at the bi-directional 
communications device, a particular one compatibility pjirameter of s£iid ALG file with both a 
compatibility feature of said bi-directional communications device. . .", the Examiner has equated 
a digital signature comparison in O'Brien to the same. However, it is respectfully pointed out to 
the Examiner that a signature (as disclosed by O'Brien) relates to a file itself and has nothing to 
do with a compatibility feature of the bi-directional communications device . 

Hence, it is clear from the onset that the Examiner has failed to set forth a prima facie 
rejection of the claims under 35 U.S.C. 103(a), as the Examiner has failed to show each and 
every element recited in the claims. 

Hence, the cited combination fails to teach or suggest the above recited limitations of 
Claim 13. 

Accordingly, Claim 1 3 is patentably distinct and non-obvious over the cited combination 
for at least the reasons set forth above. Therefore, withdrawal of the rejection and allowance of 
Claim 13 is earnestly requested. 
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G. Conclusion 

At least the above-identified limitations of the pending cMms arc not disclosed or 
suggested by the teachings of the cited references. Accordingly, it is respectfully requested that 
the Board reverse the rejections of Claim 1, 2, 4, 11-14, 16-18, and 21-32 under 35 U.S.C. 112 

and § 103(a). 

No fee is believed to be due to accompany this submission. However, in the event of any 
non-payment or improper payment of a required fee, the Commissioner is authorized to charge 
Deposit Account No. 07-0832 as required to correct the error. 
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